Turnbull China Bikeride/Turnbull China Bikeride - Disc 2.iso/BARNET/ARMLINUX/MAIL/9804/[e-mail] _Mon Apr 20 10:57:49 1998.msg

Internet Message Format | 1998-05-13 | 6KB

Return-Path: <[e-mail]>
Received: from lenzie.cent.gla.ac.uk (lenzie.cent.gla.ac.uk [130.209.16.18])
    by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id KAA14984
    for <[e-mail]>; Mon, 20 Apr 1998 10:57:48 +0100
Received: from localhost (9606585c@localhost)
    by lenzie.cent.gla.ac.uk (8.8.4/8.8.8) with SMTP id KAA03216;
    Mon, 20 Apr 1998 10:57:39 +0100 (BST)
Date: Mon, 20 Apr 1998 10:57:37 +0100 (BST)
From: James Craig <[e-mail]>
X-Sender: [e-mail]
Reply-To: James Craig <[e-mail]>
To: Russell King - ARM Linux Admin <[e-mail]>
cc: James Craig <[e-mail]>, [e-mail],
        [e-mail], [e-mail]
Subject: Re: fd0* device for ADFS shape discs under i386 Linux
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO

On Sun, 19 Apr 1998, Russell King - ARM Linux Admin wrote:

> James Craig writes:
> > On Fri, 17 Apr 1998, Matthew Wilcox wrote:
> > >Andrew Bower
> > >> Out of interest, is anyone working on write support for ADFS?
> > >
> > >I've looked at the current code.  It would be hard to add extendable
> > >files to it, though in principle, files which are newly created and stay
> > >the same length should be able to work quite easily.
> > >
> > >The trouble is that ADFS (or more truthfully filecore) does not have
> > >the concept of the inode.  Inodes are what Unix filesystems are built of.
> > >They have the following properties:
> > >
> > >Each file has an inode
> > >The inode remains the same during the life of the file
> > >Inodes do not map to more than one file.
> > >The inode contains all of the metadata for the file except its name.
> >
> > umm. ADFS doesn't have inodes in the same way UNIX does, but couldn't you
> > get away with the file's ID that appears in the free space map? (He said,
> > trying to talk knowledgably, despite the fact that it's 5 years since he
> > last wrote an ADFS-E-format-filing-system-reader).
>
> I did toy with that idea, after all,  it is quite unique.  However, you stumble
> on a small problem:
>
> Under Unix, a filename translates to an inode.  An inode then gives you the
> file data, and attributes.
>
> Under Filecore, a filename translates to a fragment ID + attributes.  A
> fragment ID translates to file data.
>
> Hence, if you do use the fragment ID for the inode number, then yes, you can
> access the file's data, but you can't get the inodes attributes, since you
> don't know where these are stored on the disk.
>
> I did at one point use a combination of the fragment ID for the parent directory
> and the fragment ID of the file, but 32-bits isn't enough to store this and
> the sector offset required.
>
> This method still isn't acceptable for a writable ADFS - if the file is moved from
> the directory to another, then it's parent ID changes...
Yeah, I can quite definately see the problem. However, could we store a
hash table of recently-accessed-inodes and just cache their directory
info? It's not like you can't search and ADFS filesystem for a particular
ID, it just takes a while. For small enough numbers of files, (say a
floppy) you could do it at mount/umount time.

> > The IDs still only map to one file, aren't likely to change over it's
> > lifetime, and the only problem you have is that the length info is kept in
> > the directory info.
>
> Exactly.
> > >Create a structure in memory for each ADFS filesystem mounted.  This can
> > >be done lazily.  Assign each file an inode based on some scheme which will
> > >allow for easy mapping between it and the name of the ADFS file.  Perhaps
> > >hash buckets.  Note that it's okay to reuse inodes once a file has been
> > >deleted.
> >
> > Ur, YUK!! That would be horrible. I mean, mapping names to inodes is gonna
> > break as soon as you move a mile about the FS somewhere.
>
> I think that this is horrible, but may be the only way.
How would it handle mv /bin/testfile /tmp/testfile, though, if the file
was still being read by another process?

> > >Someone should look at other filing systems to see how they cope with
> > >filesystems that don't provide nice inodes.  When Dickon Hood & I were
> > >experimenting with NFS servers under RISC OS, we had a structure that
> > >worked well; it was a tree, and the inode we returned was the address
> > >within that list.  You've got me intrigued now, I might just do it.
> >
> > Good man, writable ADFS would be nice. :)
> >
> > >The way Russell has done it is faster than this method for read-only
> > >but will not extend to writable files.
> >
> > I haven't looked at it yet, but what's he done that stops you writing
> > files the same way?
>
> The problem is that the inode number depends on the position of the directory
> on the disk and the offset into the directory.  If you add a file, then
> as far as the Linux VFS is concerned, all the inodes on that disk have changed,
> and all inodes must be refreshed.  NFS will go mad (since it depends on inodes
> staying the same), as will things like `pwd'.
>
> Linux needs to be able to map an inode number directly to a file on ADFS -
> this is the first problem that someone's going to have to crack when allowing
> ADFS to be writable.

Truly. I've written ADFS file readers and writers before, but I've never
tried integrating one into a totally different OS's idea of a filing
system. In the meantime, we could probably fairly quickly code up an ADFS
equivalent of the mtools for DOS - The old IscaFS that Phil Norman wrote
would do the job just fine if we could manage to fiddle it to run under
Linux. :)
-- James Craig
   <[e-mail]>